problem

The very first request to Queue API is slow due to sending a list of test files from the disk. The bigger the test files list the slower is request. For a few thousand test files it can take 1+ second.

When a lot of requests from parallel CI nodes starting at the same time hit the Knapsack Pro API this can lead to slower performance of the API because requests with a list of test files can be slow. This leads to compound effect and degradation of API performance for very large projects using ~100+ parallel CI nodes.

When you use RSpec split by test examples feature then each parallel CI node must generate a JSON report with test example ids in order to prepare a list of test files that must be sent to API. This can be slow. By introducing an attempt to connect to the existing Queue on the API side we can avoid this slow operation of reading test files from disk or from JSON report for RSpec test examples.

Only the very first request (or a few concurrent requests from parallel CI nodes that hit API at the same time) will start 2nd request responsible for initializing the Queue on the API side based on a list of test files from disk (reading test files is slow operation especially for RSpec split by examples feature).

solution

• make attempt to connect to the existing Queue on the API side and don't' send a list of test files from the disk
• if the above attempt failed then send a list of test files from the disk to initialize a new Queue on API side

Thanks to the above we can significantly reduce the number of slow requests and make the overall API more stable.

We can also start running tests faster for most parallel CI nodes that will start work after the queue was already initialized on the API side. This reduces start time by a few seconds or even more for the large test suites that use RSpec split by test examples feature.

WARNING ABOUT BUG

This PR accidentally introduced a bug in RSpec split by test examples feature. Here is the fix: #135